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REMARKS 

Claims 1 - 17 are pending in the present application. No amendment has been 
proposed. It is respectfully submitted that this Amendment is fully responsive to the 
Office Action dated May 6, 2005. 

Information Disclosure Statement (IDS): 

It is respectfully submitted that the Examiner failed to consider the IDS filed on 
November 12, 2004 by the Applicant. As such, it is requested that the Examiner properly 
consider such IDS and provide Applicant with an initialed copy of the accompanied PTO 
Form- 1449 filed with the IDS on November 12, 2004. 

35 U.S.C. 112. First Paragraph Rejection: 

Claims 1-17 are rejected under 35 USC 1 12, first paragraph, as failing to comply 
with the enablement requirement. The claims contain subject matter, which was not 
described in the specification in such as way as to enable one skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and/or use the invention. This 
rejection is respectfully traversed. 

The Examiner asserts: 

In referring to claim 1, the "step of regenerating the data attribute table and the 
retrieval data table" when there is no information between serialized data items. . . . 
The specification of the instant application gives an example of serialized data 
(Fig. 9, element 38) that is to be regenerated as a table. This is to be done with the 
control data with consists of "data size 41, method of compression 42, size of the 
compressed data 43 and return code 44" (page 23, lines 21-22). It is unclear as to 
how the serialized data string would be regenerated, as each data item is (or could 
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be) a different size. If the control data contains the size of each of the individual 
data items then the control data would contain the same number of elements as the 
returned string. This disclosure would not enable any person skilled in the art to 
make and use the subject matter defined by each of the rejected claims without 
undue experimentation. 

However, it is respectfully submitted that the Examiner is clearly mis- 
characterizing the features of the present claimed invention. 

More specifically, claim 1 was amended in the previous amendment dated 
November 12, 2004 to recite a transmission data generating step of serializing all items 
contained in the data attribute table and retrieval data table into a single string without 
adding additional information between the items . 

As the Examiner noted, Fig. 9 of the present application shows an example of the 
transmission data 38 generated from the data tables shown in Fig. 7 and Fig. 8, which 
information contained in each item of each row of the data attribute table 36 and the 
retrieval data table 37 is simply connected into a single string of a text data without any 
information between added between the items. That is, the transmission data generating 
step converts a number of data included in the tables into a single string of data. 

Then, as shown in Fig. 10 of the present application, the control information adding 
means 20 adds the control information 39 to the head of a compressed transmission data 
40 (SI 08) and not between the items in the single string. 
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That is, since size, items and so on of the retrieval data table are different every time 
the retrieval is made, information on these characteristics must be sent to the client 
machine in order to regenerate the tables from the transmission data which is sent in the 
form of the single string. For this reason, the control information in accordance with the 
characteristic of the transmission data is added to the head of the transmission data. 
Adding these pieces of control information enables the receiving side to quickly reserve a 
necessary size of memory area for example, facilitating smooth transmission of the data. 

Claim 1 also recites the data table regenerating step of regenerating the data 
attribute table and the retrieval data table in a memory area on the client side, from the 
transmission data transmitted. 

For example, Fig. 6 shows a processing procedure of received data on the client side. 
The data sent from the server 3 is received by the data reception-transmission processing 
means 12 of the client machine 4 (S201). The control information of the received data is 
read to determine if there is need for decompression (S202). If the data is compressed, the 
data decompressing means 34 restores the string data 38 shown in Fig. 9 (S203). 

Next, the data attribute table 36 and the retrieval data table 37 shown in Fig. 7 and 
Fig. 8 are separated from the data string 38 and stored in a memory area of the client 
machine by the data table regenerating means 33 (-S204). With the above procedure, the 
same data as retrieved in the server is formed in the client machine. 
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In addition, the Examiner considers "It is unclear as to how the serialized data string 
would be regenerated, as each data item is a different size." 

In a relational database, data takes a form of table. A table is made up of a number of 
rows having the same structure. Each of the rows contains items. The size of data is decided 
with the number of rows, and the size of each item of the same column being fixed. Since 
the character strings of each attribute data is limited by SQL, attribute data (table) is 
regenerated easily from the serialized data string without adding additional information 
between the items. Therefore, a retrieval data table is regenerated if the attribute of each item 
is known. 

In view of the above, it is respectfully submitted that one of ordinary skill would be 
able to make and/or use the subject matter of present claimed invention as described in the 
present specification as originally filed. Accordingly, withdrawal of this rejection is 
respectfully requested. 

As to the Merits: 

As to the merits of this case, the Examiner maintains the following rejections: 

1) claims 1,6-9 and 15 were rejected under 35 U.S.C. §102 over Heilsberg et al . 
(USP 6,151,602); 
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2) claims 4 and 5 were rejected under 35 U.S.C. §103 over Hejlsberg ; and 

3) claims 2, 3, 10, 11, 12, 14 and 16 were rejected under 35 U.S.C. §103 over 
Hejlsberg , in view of CoganetaL (USP 5,406,380). 

Each of these rejections is respectfully traversed. 

As previously pointed out in the last response filed November 12, 2004, 
independent claims 1,7, 10, and 15 recite, inter alia, "a transmission data generating step 
of serializing all items contained in the data attribute table and retrieval data table into a 
single string without adding additional information between the items ." 

In response to applicant's arguments that the cited prior art do not teach or suggest 
this feature, since Hejlsberg relies on the existence of the intervening descriptors in the 
data stream (including the inserted row data header information mentioned above) in order 
to achieve a correct interpretation of the stream data (see e.g. column 21, lines 1 - 4), the 
Examiner fails to provide any response or argument. 

That is, the Examiner fails to provide any rebuttal concerning applicant's position 
that such teachings in the primary reference to Hejlsberg are directly contrary to the 
present invention that avoids inserting such additional information between each item, and 
that the primary reference to Hejlsberg is contrary to the present claimed "serializing all 
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items contained in the data attribute table and retrieval data table into a single string 
without adding additional information between the items." 

That is, the feature of this invention is that "serializing all items contained in the 
data attribute table and retrieval data table into a single string without adding additional 
information between the items ." 

The data format of Heilsberg (Hejlsberg Fig. 4) is for a packet data that is divided by the 
operation system (TCP/IP). 

On the other hand, the data format of the present invention, for example, Fig. 10, is 
for application data (data base software) before being divided by the operation system. 

In the case of Heilsberg , a column descriptor is added to each packet data. After a 
client receives the data packet, each packet data is rebuilt by the column descriptor first 
(Hejlsberg Fig. 4, step 602), and all data records of the data packet are looped ( Hejlsberg Fig. 4, 
step 605). 

On the other hand, in the present invention, attribute information (data attribute 
table) is not added to each packet data. Instead, the applicant deals with attribute information 
as an independent data table as well as a retrieval data table. And the attribute information and the 
retrieval data are unified as serializing data, compressed as one, and divided into a packet after 
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that, Therefore, attribute information (column descriptor) is not contained in all packets. 

That is, in present invention, a retrieval data table is regenerated only by sending the 
attribute information once. Therefore, the amount of data transmitted decreases extremely. 

In view of the aforementioned remarks, Applicants submit that that the claims are 
in condition for allowance. Applicants request such action at an early date. 

If the Examiner believes that this application is not now in condition for allowance, 
the Examiner is requested to contact Applicants' undersigned attorney to arrange for an 
interview to expedite the disposition of this case. 

If this paper is not timely filed, Applicants respectfully petition for an appropriate 
extension of time. The fees for such an extension or any other fees that may be due with 
respect to this paper may be charged to Deposit Account No. 50-2866. 

Respectfully submitted, 




Attorney for Applicants 
Registration No. 44,450 
Telephone: (202) 822-1100 
Facsimile: (202) 822-1111 
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